/test e2e-aws

we are going to give this another go PTAL

/cc @smarterclayton

/hold cancel

/test e2e-aws

@sttts requested we move this to a more appropriate place. Where is this value actually used? Machine-config-operator? If so it belongs there.

@smarterclayton the image is used by bootstrap node via installer https://github.com/openshift/installer/blob/af56e2db2e2601156a1ebe56269c7deb67f3c725/data/data/bootstrap/files/usr/local/bin/bootkube.sh.template#L225.

The endpoint it creates is consumed by etcd init https://github.com/openshift/machine-config-operator/blob/8381bc2c071125feb44c8b3bee25a8453cc0efe5/templates/master/00-master/_base/files/etc-kubernetes-manifests-etcd-member.yaml#L42

I am sure you know this but it is unclear to me where that makes it land.

@abhinavdahiya if it's consumed by something in MCO I think the best place to take the reference is there. This code knows nothing about specific components, and even though in the future I could see us moving bootkube.sh to functionality in this repo at the current time it's a thin shim deliberately. Opinions?

@abhinavdahiya if it's consumed by something in MCO I think the best place to take the reference is there. This code knows nothing about specific components, and even though in the future I could see us moving bootkube.sh to functionality in this repo at the current time it's a thin shim deliberately. Opinions?

The MCO consumes the kube-client-agent to request etcd certs from kubernetes CSR api and therefore we have that declared as dependency in MCO repo https://github.com/openshift/machine-config-operator/blob/master/install/image-references#L41

the kube-etcd-signer-server is used to bootstrap the etcd cluster by mimic-ing the kubernetes CSR api on the bootstrap node. So this is image is more to the effect of special component used on the bootstrap node required for cluster bootstrapping and therefore, IMO this is correct location for this and not dirty hack as per here

Is bootkube the component that creates the reference?

Is bootkube the component that creates the reference?

Hmm 😕 what reference ?

The reference to the image kube-etcd-signer-server by calling cluster-version-operator image?

The reference to the image kube-etcd-signer-server by calling cluster-version-operator image?

from @hexfusion comment

@smarterclayton the image is used by bootstrap node via installer https://github.com/openshift/installer/blob/af56e2db2e2601156a1ebe56269c7deb67f3c725/data/data/bootstrap/files/usr/local/bin/bootkube.sh.template#L225.

the bootkube.sh service on the bootstrap node calls the reference.

Why doesn't installer take the reference?

Why doesn't installer take the reference?

cluster-bootstrap is also only used by installer on bootstrap node and we have image decalaration in this repo

IMO keeping the image requirements for bootstrap node here cluster-bootstrap keeps it more compartmentalized.. ?

@smarterclayton @abhinavdahiya have we come to an agreement?:) This is now a blocker for etcd metrics.

/retest

@sttts would you mind chiming in on this I know you were against this initially.

@hexfusion dependencies for bootkube.sh do belong where bootkube.sh is stored. Today, cluster-bootstrap knows nothing about the bootkube.sh bootstrapping process. Any etcd dependency here is on the wrong layer: cluster-bootstrap is only a generic tool launching some static pods and creating some manifests. It has no knowledge about what it actually creates.

I could imagine a world where we move the bootkube.sh logic into cluster-bootstrap, like a cluster-bootstrap render bootkube.sh | bash command called by the bootstrap node. If all are on the same page with this vision, this PR would be in line.

/test e2e-aws

@hexfusion dependencies for bootkube.sh do belong where bootkube.sh is stored. Today, cluster-bootstrap knows nothing about the bootkube.sh bootstrapping process. Any etcd dependency here is on the wrong layer: cluster-bootstrap is only a generic tool launching some static pods and creating some manifests. It has no knowledge about what it actually creates.

I could imagine a world where we move the bootkube.sh logic into cluster-bootstrap, like a cluster-bootstrap render bootkube.sh | bash command called by the bootstrap node. If all are on the same page with this vision, this PR would be in line.

cluster-bootstrap render bootkube.sh | bash makes sense

/lgtm

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: hexfusion, mfojtik

The full list of commands accepted by this bot can be found here.

The pull request process is described here

/test e2e-aws

/retest

Please review the full test history for this PR and help us cut down flakes.

/test e2e-aws